NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/905

Text File | 1996-08-06 | 5.7 KB | 112 lines

Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.lang.eiffel,comp.lang.smalltalk
Path: beatty.slip.netcom.com!beatty
From: [e-mail] (Derek Lee Beatty)
Subject: Re: whither style
Message-ID: <4cnmqu$[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: beatty.slip.netcom.com
Organization: none
X-Newsreader: Alexandra.app (Version 0.81)
References: <[e-mail]> <[e-mail]> <4bvae4$[e-mail]> <4c0a6d$[e-mail]>
Date: Sun, 7 Jan 1996 05:48:14 GMT

[e-mail] (Jean-Marc Jezequel) wrote:
>
>Please note that most of the HN (Hungarian Notation) discussion
>is led in the C and C++ context only.  In Eiffel or Smalltalk,
>where everything is an object, it would be really *stupid* to use
>such a restricted notation: types such as Integer or Float are
>nothing special w.r.t the language, and they are no more important
>than e.g., linked_list_of_hash_table_of_foo.

Although I know little about Eiffel, I'm quite cognizant of Smalltalk's type
system, and I concede from that (rather narrow) viewpoint Integer and Float
are not special.  However, from the standpoints of utility or simplicity of
concept, there is something fundamental about concepts such as Number or
Symbol, and from the standpoint of efficiency, there is something fundamental
about hardware-supported types.

This actually brings up an interesting question: is the appropriateness of a
naming convention related more to the nature of the problem domain, or more
to the nature of the programming language?  Maybe the former.  Every
well-written moderate or large software system I've seen is layered, and the
higher levels make use of problem-domain abstractions.  These abstractions
are largely independent of the programming language.  This then argues that
the importance of type distinctions, and consequently the visibility they
should have in the source code, is a function of the problem domain.

In my work, one hallmark is multiplicity of representation.  External
constraints very often dictate that I maintain numerous representations of
the same underlying thing.  Maintaining this correlation consistently and
clearly in the source code is important.  There HN is useful because we can
use the same "base name" for both representations, and let the "Hungarian"
prefix distinguish them.

Certainly, we could invent our own naming convention to solve the problem,
but why bother when an existing naming convention serves well?  This frees
our attention so we can turn to more important concerns (like how to reduce
the number of different representations).

>Beside, languages such as Smalltalk, Ada, Modula, Eiffel are not
>half-backed about typing:  either they are not typed (actually
>dynamically type), or strongly typed. In both cases, HN is mostly
>irrevelant. Idem for allocation classes, global vs. local, etc.:
>in Eiffel for instance you do not have to mess with this low level
>stuff (but you can if you want so).

As to typing, I have to disagree, having found HN quite useful on a project
where I used ANSI C with full "function prototypes" (why couldn't C call them
something more reasonable like "interface defintions") where strong typing
was enforced.  But as I said above, the utility of HN could be more a
function of my problem domain.

As to allocation, inattention to storage management is probably the source of
much of the perceived inefficiency of advanced languages relative to
lower-level ones like C++.  Garbage collection allows one to ignore storage
management for too long---after all, by construction there are no
memory-mangement bugs---until the memory footprint has ballooned.  In a
virtual-memory environment, once your working set exceeds the capacity of the
translation lookaside buffer, performance plummets.  (That said, I still
prefer GC; it lets me worry about memory management only when that is truly
necessary; without it I must be ever vigilant.)

As to scope, surely if you're smart enough to use Eiffel you're not using
global variables, or at least not very many of them, or at least not without
some clear way to distinguish them.  Actually, I'm a bit surprised that
Eiffel has global variables, but you brought them up.

>Since you are in a really modular language (Ada*, Modula*, Eiffel,
>Smalltalk) the declaration of a variable type should be located
>close to its uses. And if your program unit is longer than a few
>tens of lines (which is poor style in e.g., Eiffel), *any* decent
>environment would show you a variable's type only by clicking on
>it.

It sometimes seems difficult for people who do research or writing about
programming (as opposed to those who actually do programming) to realize, but
not all activities related to programming are conducted in "programming
environments."  Code is discussed in email, and in company-private
newsgroups, and in meetings called "code reviews" which typically are done
from printed listings.  And yes, a good environment will show me a variable's
type just by clicking on it, but with HN I know the type just by *looking* at
it, and looking is even easier than clicking.

>So in conclusion, HN really are
>...
>>programming conventions ... developed to compensate for language flaws, are
>...
>
>thus mostly relevant to C and C++. So please keep the discussion
>in these groups.

Were that to be done, this thread would die just when it is becoming more
interesting.  The assertion has been made that language and technology better
solve the problem that HN attempts to address.  I disagree because I prefer
three tools to two (and I'm not convinced that language is relevant at all).

--
Derek Lee Beatty      _
[e-mail]          _| ~-,
Austin, Texas              \, * )
              \_(